PR: Fix "No such feed" race condition on subscriber reconnect

Problem

When multiple clients reconnect simultaneously (e.g. after a proxy timeout or network
interruption), subscribers frequently fail to receive audio/video from publishers with
No such feed (N) error from Janus VideoRoom, leaving them unable to hear other
participants despite the call appearing active.

Root cause: lost wakeup in async.Notifier

The retry logic in sfu/janus/subscriber.go relies on newPublisherConnectedWaiter
which uses async.Notifier to wait until the publisher signals it is connected (via
webrtcup event → notifyPublisherConnected).

The race condition:

Time →
  Publisher: webrtcup fires → notifyPublisherConnected() → Notify("pub_X")
             [no waiters exist yet — notification is LOST]
  Subscriber: tries joinRoom → "No such feed"
              → creates waiter → waiter.Wait(ctx) blocks forever
              → context expires → subscriber gives up

async.Notifier.Notify() only wakes existing waiters; if none exist at the time of
notification, the event is permanently lost. Subscribers created after the publisher
connected never receive the signal and wait until context timeout.

Secondary issue: busy-loop after sticky fix

The original code creates the waiter once before the retry loop:

waiter, stop := p.mcu.newPublisherConnectedWaiter(...)
defer stop()

retry:
    // join attempt
    waiter.Wait(ctx)   // same object reused
    goto retry

If NewWaiter returns an already-closed channel (sticky behavior), subsequent
Wait() calls on the same waiter return immediately → tight busy-loop spamming
Janus with join requests until context expiry.

Fix

1. async/notifier.go — sticky notifications (30-second TTL)

Notifier now remembers the timestamp of the last Notify() call per key.
NewWaiter() checks: if the key was notified within the last 30 seconds, it returns
an already-closed channel so the caller retries immediately instead of waiting
indefinitely.

Reset() clears notifiedAt together with the waiter maps to prevent stale signals
after a publisher leaves and rejoins.

2. sfu/janus/subscriber.go — waiter created inside retry loop

Move newPublisherConnectedWaiter inside the JANUS_VIDEOROOM_ERROR_NO_SUCH_FEED
case, creating a fresh waiter on every retry iteration:

retry:
    // join attempt
    case janus.JANUS_VIDEOROOM_ERROR_NO_SUCH_FEED:
        waiter, stop := p.mcu.newPublisherConnectedWaiter(p.publisher, p.streamType)
        if err := waiter.Wait(ctx); err != nil {
            stop()
            ...
        }
        stop()
        goto retry

This eliminates the busy-loop: each iteration creates a new waiter. If the publisher
was already connected (sticky signal within TTL), the new waiter returns immediately
and the retry join succeeds. If the publisher is not yet connected, the waiter blocks
until the signal arrives.

Observed behaviour after fix

Production system (Nextcloud Talk 23.0.4, spreed-signaling 2.1.1, Janus 1.4.0):

• Before fix: No such feed errors in clusters of 10–44 per reconnect event,
  affecting 2–5 users per incident, occurring ~10 times per day during business hours
• After fix: No such feed = 0 across multiple reconnect events

Testing

The race can be reproduced by:

1. Starting a multi-participant call
2. Forcing simultaneous WebSocket reconnect of all HPB clients
   (e.g. restart the signaling server or expire proxy timeout)
3. Observing whether subscribers receive audio after reconnect

Without fix: some subscribers get No such feed and never receive audio.
With fix: all subscribers successfully subscribe after retry.